
Security Systems to Include Remote Locations 


The 10 Golden Rules of Network Security 


Synchronizing Security Information 
Across Mixed MVS/VM Systems 


http://www.naspa.net 


NetWare Auditing 



SEPTEMBER 1 997 

Volume 5. Number 9 


SYSTEMS 


16 Extending Existing Security Systems 
to Include Remote Locations 

By Gordon Bennett 
This article examines what features 
to look for when evaluating 
security software to extend 
the capabilities of RACF, 

CA- ACF2, and CA-Top Secret 
to include remote users, teleworkers, 
consumers, and business partners. 



32 Synchronizing Security Information 
Across MVS/VM Systems 

By Ed Blunt 

This article examines the security 
challenges facing sites 
with mixed MVS/VM 
systems and different 
security packages, 
and presents solu- j 
tions to their pass- ! 
word synchroniza¬ 
tion problems. 




8 Testing. Testing. 1 -2-3: The Critical Step in Year 2000 Projects — Part II 

By James S. Huggins and C.E. Scott 

In theory, software testing may be simplistic, but when applied to the Year 2000, 
it becomes enormously difficult. This article examines several problems that 
may be encountered in the testing cycle of the Y2K conversion and offers some 
suggestions to solve these problems. 

20 OpenEdition MVS and the Bourne Shell: A User Experience — Part III 

Troubleshooting OpenEdition MVS Shell Problems 

By Evan Galen 

This concluding article presents tools for gathering information on the failure 
situations which arose from the functional comparisons of OpenEdition MVS 
and the SunOS Bourne shell, and presents some general conclusions 
on OpenEdition MVS. 

24 Year 2000 Solutions for Recovering Lost Source Code 

By Leland G. Freeman 

Recovery of source code can be performed faster and more cost-effectively 
without the need for COBOL programmers to replace the missing source. 



36 The 10 Golden Rules 
of Network Security 

By Chip Me sec 

With unauthorized use of computer 
systems increasing, the most effective 
way to secure an IS orga¬ 
nization is to become 
better educated and 
make security part of | 
your day-to-day job. 


46 Using NetWare 4 Auditing 

By John E. Johnston 
NetWare 4 provides an auditing 
facility that allows network 
administrators to 
monitor changes to the 
file system and the NDS 
structure, as well as verify 
system security, trouble¬ 
shoot applications, and 
monitor access to highly 
sensitive data. 
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51 UNIX, Windows NT, and NetWare — A Comparative Analysis: Part I 

By Guy C. Yost 

Although the ideal platform would measure favorably as both a Network 
Operating System and an Application Server in an enterprise environment, UNIX, 
NetWare, and Windows NT all have their strengths and weaknesses that amount 
to each product being best suited for one purpose or another. 
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S/2 INSIGHTS 


Building the Perfect Beast: 
Part III — Customization 

BY MIKE NORTON 


O ne thing I will admit that Windows 95 
does better than OS/2 is cater to user 
psychology. For instance, Fve always 
admired the “Starting Windows 95 for the 
very first time” screen, which appears when 
booting Windows 95 after installation. 
There’s something singularly special 
about booting to a new operating system — 
an operating system without the burdens 
of past sins, free from the consequences 
of the abuse I tend to heap upon an oper¬ 
ating system. The effect is so pleasant. 
I’ve often wondered why many of the 
poor souls I’ve spoken with were willing 
to spend days tracking down and correcting 
some glitch that a few hours reinstalling 
would resolve. 


RESOLVING OPERATIONAL GLITCHES BEFORE 
CUSTOMIZATION 

The answer, of course, lies in customiza¬ 
tion, particularly of the OS/2 Desktop. 
Indeed, it is almost unbearably tempting 
after a new installation to start organizing 
icons, change backgrounds, and set folder 
behavior. Don’t. Make sure your system is 
fully functional and resolve any operational 
glitches before investing in customization. 
I’ve been burned more than once installing 
applications and customizing a system only 
to find out something didn't go quite as 
I intended during installation, leading to 
being impaled on the horns of the dilemma: 
to reinstall and lose my customization 
or hack it out and start out life with a com¬ 
promised install. Try it before you buy it. 
Ensure that the network is working properly, 
devices are functioning correctly, and 
WINOS2 is accessible before moving a 
single icon or installing any application. 
If possible, I try to let a system “cure” for 
a couple of days, using only the applica¬ 
tions provided with the operating system 


Configuring and fine-tuning 
the OS/2 command environment 
may not be as appealing as an 
exquisitely customized desktop, 
but ultimately the underlying batch 
environment is the heart 
of the perfect beast. 


before any customization or installation 
of application software. 

AN EXCEPTION TO THE RULE: 40S2 

There is one application for which I 
make an exception: 40S2 gets installed as 
soon as I get rebooted. Indeed, whether I’m 
using DOS, Windows NT, or OS/2, the 
popular line of products from JP Software, 
Inc., always goes first on my system. For 
those of you who are not familiar with 
4DOS and its offspring for OS/2 and NT, 
40S2 provides a replacement command 
processor with enhanced functionality. The 
LIST command alone is worth picking up a 
copy of 40S2: It allows you to browse a file 
in the command session — meaning it is 
lightening fast. 40S2 also allows you to 
assign file descriptions up to 511 characters 
to files, storing the filename and description 
in a text file in the directory (I rename the 
default description file to 00index.txt, since 
the format is the same as the familiar UNIX 
convention). 40S2 Aliases allow you to 
create in-memory batch files to quickly 
execute frequently used commands and 
procedures. For more information on 40S2, 
visit JP Software, Inc.’s website at 
http://www.jpsoft.com. 


Once I’ve installed 40S2, I then use a 
REXX command file to assign a generic 
file description (“OS/2 installation”) to 
every file on the operating system partition. 
This allows me to keep track of files added 
to my system after installation — 40S2 
provides a facility for searching by descrip¬ 
tion, which, in turn, allows me to avoid a 
mile-long LIBPATH statement: I simply 
dump DLLs from applications into the 
OS2\APPS\DLL directory, which is already 
included in the LIBPATH. I’m increasingly 
doing the same thing with executables. The 
advantage, of course, is that it takes less 
time to read one directory in the PATH or 
LIBPATH statement than it does to read 
multiple directories. 

For similar reasons, I reorganize my 
LIBPATH and PATH statements to my own 
personal pecking order. Not only does this 
improve speed, it allows me to dictate the 
order in which files are found. By placing 
the directory that contains command files at 
the beginning of the PATH statement, I can 
provide my own defaults and switches for 
external commands such as CHKDSK, or 
any program for that matter. Many of you 
may already be familiar with this technique 
from using .BAT files to set up the environ¬ 
ment and launch .EXE files bearing the 
same name under DOS. However, it is my 
observation that overall the majority of 
users overlook the rich batch environment 
which OS/2 provides and ignore the fact 
that the same fundamental principles and 
techniques of the DOS environment apply 
to OS/2. 

While I'm altering my CONFIG.SYS, 
I spend a few moments organizing and 
sorting this most important of files (after 
prudently backing it up, of course). 
Although there are a number of utilities 
available for the task (and some of them are 
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quite good), I prefer to manually perform 
this chore. The educational value alone is 
worth the time and effort: I would highly 
recommend any new user open up the OS/2 
command reference and other related publi¬ 
cations and learn the function of each of the 
statements in the CONFIG.SYS. Be care¬ 
ful, though: In some cases, certain state¬ 
ments must appear in a particular order. I’ve 
never run into this problem organizing my 
CONFIG.SYS, but I have encountered this 
when installing certain options, most 
notably PCMCIA support. Just be sure you 
keep handy a copy of the CONFIG.SYS file 
that you know works. 

ENVIRONMENTAL VARIABLES 

One of my areas of organization in the 
CONFIG.SYS includes environmental vari¬ 
ables which are, of course, eternally inter¬ 
twined with my arsenal of batch command 
files. Those of you from PC or UNIX shops 
are almost certainly familiar with environ¬ 
mental variables, but those of you migrat¬ 
ing from mainframe shops may not be at all 
familiar with them. The' most common use 
of environmental variables is to maintain 
path information independent of the actual 
physical path, much like dataset names. 
Thus, if I have included a SET 
MYPATH=C:\FOO in my CONFIG.SYS, 
my command files can reference 
%MYPATH\FILENAME.EXT (the percent 
sign identifying MYPATFI as an environ¬ 
mental variable), which is translated into 
C:\FOO\FILENAME.EXT on execution. 
This means that I can subsequently move 


Part of building the perfect beast 
so to speak, is recognizing 
the nature of the beast, 
and I am of the opinion 
that many users have come 
to confuse the PM/WPS GUI 
front-end to OS/2 with OS/2 itself. 


the FOO directory to another drive or direc¬ 
tory and simply modify the SET statement 
in the CONFIG.SYS to update all refer¬ 
ences. Environmental variables are also 
useful at the command line, especially 
when a pathname becomes unwieldy. 
Setting an environmental variable PROJ to 
C:\DEVL\C\SOURCE\PROJ allows chang¬ 
ing to the project directory by issuing the 
much shorter command CD %PROJ. Thus, 
environmental variables have become an 
important part of my system, and upon 
installing a new operating system, updating 
the CONFIG.SYS to include my stock of 
environmental variables is one of the first 
chores I perform. 

THE HEART OF THE PERFECT BEAST 

Between 40S2 aliases, command files, 
REXX, and environmental variables, I can 
move around fluidly and effectively at the 
command prompt. Indeed, you may have 
noticed I haven’t even touched the OS/2 


Desktop yet, except to open an OS/2 win¬ 
dow. Part of building the perfect beast, 
so to speak, is recognizing the nature of 
the beast, and I am of the opinion that 
many users have come to confuse the 
PM/WPS GUI front-end to OS/2 with OS/2 
itself. They are not the same thing; these 
are optional facilities loaded in the 
CONFIG.SYS. Configuring and fine-tuning 
the OS/2 command environment may not be 
as appealing as an exquisitely customized 
desktop, but ultimately the underlying 
batch environment is the heart of the 
perfect beast. E3 

Was this column of value to you? If so, 
please circle Reader Response Card No. 45. 



Michael Norton is the workstation division manager 
at SofTouch Systems, Oklahoma City, Okla., which 
provides both mainframe and PC software solutions. 
He has written mainframe manuals in addition 
to articles for a number of publications. Michael 
can be contacted at mnorton@softouch.com. 
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